---
title: nx.json Reference
description: A comprehensive reference for the nx.json configuration file, which controls Nx CLI behavior, project defaults, and workspace settings.
sidebar:
  order: 2
  label: Nx Configuration
filter: 'type:References'
---

The `nx.json` file configures the Nx CLI and project defaults. The full [machine readable schema](https://github.com/nrwl/nx/blob/master/packages/nx/schemas/nx-schema.json) is available on GitHub.

{% aside type="note" title="Nx 22 Changes" %}
Release tag configuration now uses a nested `releaseTag` object (e.g., `releaseTag.pattern` instead of `releaseTagPattern`). Old properties work until Nx 23.

See [Release Tag](#release-tag) for details.
{% /aside %}

The following is an expanded example showing all options. Your `nx.json` will likely be much shorter.

```json
// nx.json
{
  "plugins": [
    {
      "plugin": "@nx/eslint/plugin",
      "options": {
        "targetName": "lint"
      }
    }
  ],
  "parallel": 4,
  "cacheDirectory": "tmp/my-nx-cache",
  "defaultBase": "main",
  "namedInputs": {
    "default": ["{projectRoot}/**/*"],
    "production": ["!{projectRoot}/**/*.spec.tsx"]
  },
  "targetDefaults": {
    "@nx/js:tsc": {
      "inputs": ["production", "^production"],
      "dependsOn": ["^build"],
      "options": {
        "main": "{projectRoot}/src/index.ts"
      },
      "cache": true
    },
    "test": {
      "cache": true,
      "inputs": ["default", "^production", "{workspaceRoot}/jest.preset.js"],
      "outputs": ["{workspaceRoot}/coverage/{projectRoot}"],
      "executor": "@nx/jest:jest"
    }
  },
  "release": {
    "version": {
      "conventionalCommits": true
    },
    "changelog": {
      "git": {
        "commit": true,
        "tag": true
      },
      "workspaceChangelog": {
        "createRelease": "github"
      },
      "projectChangelogs": true
    }
  },
  "sync": {
    "globalGenerators": ["my-plugin:my-sync-generator"]
  },
  "generators": {
    "@nx/js:library": {
      "buildable": true
    }
  },
  "extends": "nx/presets/npm.json",
  "tui": {
    "enabled": true,
    "autoExit": true
  },
  "conformance": {
    "rules": [
      {
        "rule": "@nx/conformance/enforce-module-boundaries",
        "status": "evaluated"
      },
      {
        "rule": "./tools/local-conformance-rules/check-project.ts",
        "projects": ["*"]
      }
    ]
  }
}
```

## Plugins

Nx plugins improve the experience of using different tools with Nx. One key feature of plugins is that they can [automatically configure the way Nx runs tasks](/docs/concepts/inferred-tasks) for a tool based on that tool's configuration. In order for a plugin to configure tasks for Nx, it needs to be registered in the `plugins` array. If a plugin has no options, it can be listed as a string. Otherwise, it should be listed as an object with a `plugin` property and an `options` property.

Every plugin behaves differently, so consult the plugin's own documentation for information about what it does. You can browse the [plugin registry](/docs/plugin-registry) for available plugins.

To learn about creating your own plugin read about [extending Nx](/docs/extending-nx/intro).

```json
// nx.json
{
  "plugins": [
    "@my-org/graph-plugin",
    {
      "plugin": "@nx/eslint/plugin",
      "options": {
        "targetName": "lint"
      }
    }
  ]
}
```

### Scope Plugins to Specific Projects

Plugins use config files to infer tasks for projects. You can specify which config files are processed by Nx plugins using the `include` and `exclude` properties in the plugin configuration object.

```jsonc
// nx.json
{
  "plugins": [
    {
      "plugin": "@nx/jest/plugin",
      "include": ["packages/**/*"], // include any projects in the packages folder
      "exclude": ["**/*-e2e/**/*"] // exclude any projects in a *-e2e folder
    }
  ]
}
```

The `include` and `exclude` properties are each file glob patterns that are used to include or exclude the configuration file that the plugin is interpreting. In the example provided, the `@nx/jest/plugin` plugin will only infer tasks for projects where the `jest.config.ts` file path matches the `packages/**/*` glob but does not match the `**/*-e2e/**/*` glob.

## Task Options

The following properties affect the way Nx runs tasks and can be set at the root of `nx.json`.

| Property                | Description                                                                                                                                                                                                                                                                                                                             |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| parallel                | defines the max number of targets run in parallel                                                                                                                                                                                                                                                                                       |
| captureStderr           | defines whether the cache captures stderr or just stdout                                                                                                                                                                                                                                                                                |
| skipNxCache             | defines whether the Nx Cache should be skipped (defaults to `false`)                                                                                                                                                                                                                                                                    |
| cacheDirectory          | defines where the local cache is stored (defaults to `.nx/cache`)                                                                                                                                                                                                                                                                       |
| encryptionKey           | (when using `"nx-cloud"` only) defines an encryption key to support end-to-end encryption of your cloud cache. You may also provide an environment variable with the key `NX_CLOUD_ENCRYPTION_KEY` that contains an encryption key as its value. The Nx Cloud task runner normalizes the key length, so any length of key is acceptable |
| selectivelyHashTsConfig | only hash the path mapping of the active project in the `tsconfig.base.json` (e.g., adding/removing projects doesn't affect the hash of existing projects) (defaults to `false`)                                                                                                                                                        |

You can configure `parallel` in `nx.json`, but you can also set a `--parallel` flag in the terminal `nx run-many -t test --parallel=5`.

## Default Base

Tells Nx which base branch to use when calculating affected projects.

- `defaultBase` defines the default base branch, defaults to `main`.

## Target Defaults

Target defaults provide ways to set common options for a particular target in your workspace. When building your project's configuration, we merge it with up to 1 default from this map. For a given target, we look at its name and its executor. We then check target defaults looking for a configuration whose key matches any of the following:

- `` `${executor}` ``
- `` `${targetName}` `` (if the configuration specifies the executor, this needs to match the target's executor as well)

Additionally, if there is not a match for either of the above, we look for other keys that may match the target name via a glob pattern. For example, a key in the target defaults that looks like `e2e-ci--**/**` would match all of the targets created by a task atomizer plugin.

Target defaults matching the executor takes precedence over those matching the target name. If we find a target default for a given target, we use it as the base for that target's configuration.

{% aside type="caution" title="Beware" %}
When using a target name as the key of a target default, make sure all the targets with that name use the same executor or that the target defaults you're setting make sense to all targets regardless of the executor they use. Anything set in a target default will also override the configuration of [tasks inferred by plugins](/docs/concepts/inferred-tasks).
{% /aside %}

Some common scenarios for this follow.

### inputs & namedInputs

Named inputs defined in `nx.json` are merged with the named inputs defined in [project level configuration](/docs/reference/project-configuration). In other words, every project has a set of named inputs, and it's defined as: `{...namedInputsFromNxJson, ...namedInputsFromProjectsProjectJson}`.

Defining `inputs` for a given target would replace the set of inputs for that target name defined in `nx.json`.
Using pseudocode `inputs = projectJson.targets.build.inputs || nxJson.targetDefaults.build.inputs`.

You can also define and redefine named inputs. This enables one key use case, where your `nx.json` can define things like this (which applies to every project):

```json
// nx.json
{
  "targetDefaults": {
    "test": {
      "inputs": ["default", "^production"]
    }
  }
}
```

And projects can define their `production` inputs, without having to redefine the inputs for the `test` target.

```json
// project.json
{
  "namedInputs": {
    "production": ["default", "!{projectRoot}/**/*.test.js"]
  }
}
```

In this case Nx will use the right `production` input for each project.

{% cardgrid %}
{% linkcard title="Inputs and Named Inputs Reference" description="Learn about all the possible settings for `inputs` and `namedInputs`" href="/docs/reference/inputs" /%}
{% linkcard title="Configure Inputs for Task Caching" description="This recipes walks you through a few examples of how to configure `inputs` and `namedInputs`" href="/docs/guides/tasks--caching/configure-inputs" /%}
{% /cardgrid %}

### Task Pipelines

Targets can depend on other targets. A common scenario is having to build dependencies of a project first before
building the project. The `dependsOn` property in `project.json` can be used to define the list of dependencies of an
individual target.

Often the same `dependsOn` configuration has to be defined for every project in the repo, and that's when
defining `targetDefaults` in `nx.json` is helpful.

```json
// nx.json
{
  "targetDefaults": {
    "build": {
      "dependsOn": ["^build"]
    }
  }
}
```

The configuration above is identical to adding `{"dependsOn": ["^build"]}` to every `build` target of every project.

{% cardgrid %}
{% linkcard title="Project Configuration reference" description="For full documentation of the `dependsOn` property, see the project configuration reference" href="/docs/reference/project-configuration#dependson" /%}
{% linkcard title="What is a Task Pipeline" description="This guide describes how to think about task pipelines" href="/docs/concepts/task-pipeline-configuration" /%}
{% /cardgrid %}

### Outputs

Another target default you can configure is `outputs`:

```json
// nx.json
{
  "targetDefaults": {
    "build": {
      "outputs": ["{projectRoot}/custom-dist"]
    }
  }
}
```

When defining any options or configurations inside of a target default, you may use the `{workspaceRoot}` and `{projectRoot}` tokens. This is useful for defining options whose values are paths.

```json
// nx.json
{
  "targetDefaults": {
    "@nx/js:tsc": {
      "options": {
        "main": "{projectRoot}/src/index.ts"
      },
      "configurations": {
        "prod": {
          "tsconfig": "{projectRoot}/tsconfig.prod.json"
        }
      },
      "inputs": ["prod"],
      "outputs": ["{workspaceRoot}/{projectRoot}"]
    },
    "build": {
      "inputs": ["prod"],
      "outputs": ["{workspaceRoot}/{projectRoot}"],
      "cache": true
    }
  }
}
```

#### Target Default Priority

Note that the inputs and outputs are specified on both the `@nx/js:tsc` and `build` default configurations. This is **required**, as when reading target defaults Nx will only ever look at one key. If there is a default configuration based on the executor used, it will be read first. If not, Nx will fall back to looking at the configuration based on target name. For instance, running `nx build project` will read the options from `targetDefaults[@nx/js:tsc]` if the target configuration for `build` uses the `@nx/js:tsc executor`. It **would not** read any of the configuration from the `build` target default configuration unless the executor does not match.

{% cardgrid %}
{% linkcard title="Configure Outputs for Task Caching" description="This recipe walks you through how to set outputs" href="/docs/guides/tasks--caching/configure-outputs" /%}
{% /cardgrid %}

### Cache

In Nx 17 and higher, caching is configured by specifying `"cache": true` in a target's configuration. This will tell Nx that it's ok to cache the results of a given target. For instance, if you have a target that runs tests, you can specify `"cache": true` in the target default configuration for `test` and Nx will cache the results of running tests.

```json
// nx.json
{
  "targetDefaults": {
    "test": {
      "cache": true
    }
  }
}
```

{% aside type="caution" title="Per Project Caching + Distribution" %}

If you are using distributed task execution and disable caching for a given target, you will not be able to use distributed task execution for that target. This is because distributed task execution requires caching to be enabled. This means that the target you have disabled caching for, and any targets which depend on that target will fail the pipeline if you try to run them with Nx Agents enabled.

{% /aside %}

### Executor/command options

You can configure options specific to a target's executor. As an example, if your repo has projects using the `@nx/js:tsc` executor, you can provide some default options as follows:

```json
// nx.json
{
  "targetDefaults": {
    "@nx/js:tsc": {
      "options": {
        "generateExportsField": true
      }
    }
  }
}
```

You can also provide defaults for [inferred targets](/docs/concepts/inferred-tasks) or targets running a command using the `nx:run-commands` executor. As an example, if your repo has projects where **all the `build` targets** run the same `vite build` command, you can provide some default options as follows:

```json
// nx.json
{
  "targetDefaults": {
    "build": {
      "options": {
        "assetsInlineLimit": 2048,
        "assetsDir": "static/assets"
      }
    }
  }
}
```

{% aside type="caution" title="Be careful" %}
If multiple targets with the same name run different commands (or use different executors), do not set options in `targetDefaults`. Different commands would accept different options, and the target defaults will apply to all targets with the same name regardless of the command they run. If you were to provide options in `targetDefaults` for them, the commands that don't expect those options could throw an error.
{% /aside %}

For more details on how to pass args to the underlying command see the [Pass Args to Commands recipe](/docs/guides/tasks--caching/pass-args-to-commands).

### Task Atomizer Configuration

Task Atomizer plugins create several targets with a similar pattern. For example, the `@nx/cypress` plugin creates a top level `e2e-ci` target and a target for each test file that looks like `e2e-ci--test/my/test.spec.ts`. To avoid having to write a target default for each of these targets, you can use a glob pattern in the target default key.

```json
// nx.json
{
  "targetDefaults": {
    "e2e-ci--**/**": {
      "options": {
        "headless": true
      }
    }
  }
}
```

{% aside type="note" title="Pattern Matching" %}
Nx uses glob patterns to match against the target name. This means that the `**/**` pattern above is required because tests can be nested within a directory which would make the target name contain a `/`. If your target name does not contain a `/`, you can use a simpler pattern like `e2e-ci-*`.
{% /aside %}

## Release

The `release` property in `nx.json` configures the `nx release` command. It is an optional property, as `nx release` is capable of working with zero config, but when present it is used to configure the versioning, changelog, and publishing phases of the release process.

For more information on how `nx release` works, see [manage releases](/docs/features/manage-releases).

The full list of configuration options available for `"release"` can be found here: [https://github.com/nrwl/nx/blob/master/packages/nx/src/config/nx-json.ts](https://github.com/nrwl/nx/blob/master/packages/nx/src/config/nx-json.ts) under `NxReleaseConfiguration`.

### Projects

If you want to limit the projects that `nx release` targets, you can use the `projects` property in `nx.json` to do so. This property is either a string, or an array of strings. The strings can be project names, glob patterns, directories, tag references or anything else that is supported by the `--projects` filter you may know from other commands such as `nx run`.

```jsonc
// nx.json
{
  "release": {
    // Here we are configuring nx release to target all projects
    // except the one called "ignore-me"
    "projects": ["*", "!ignore-me"]
  }
}
```

### Projects Relationship

The `projectsRelationship` property tells Nx whether to release projects independently or together. By default Nx will release all your projects together in lock step, which is an equivalent of `"projectRelationships": "fixed"`. If you want to release projects independently, you can set `"projectsRelationship": "independent"`.

```jsonc
// nx.json
{
  "release": {
    // Here we are configuring nx release to release projects
    // independently, as opposed to the default of "fixed"
    "projectsRelationship": "independent"
  }
}
```

### Release Tag

The `releaseTag` property controls how git tags are parsed and generated. By default tags conform to semantic version and are validated as such.

{% aside type="note" title="Nx 22 Changes" %}
Release tag configuration now uses a nested `releaseTag` object. Old flat properties (`releaseTagPattern`, etc.) are deprecated but work until Nx 23.

**Nx 22+:** `releaseTag.pattern`, `releaseTag.requireSemver`, `releaseTag.strictPreid`

**Nx < 22:** `releaseTagPattern`, `releaseTagPatternRequireSemver`, `releaseTagPatternStrictPreid`
{% /aside %}

#### Configuration Options

| Property                 | Type    | Default                                                           | Description                                                                                                  |
| ------------------------ | ------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **pattern**              | string  | `v{version}` for fixed, `{projectName}@{version}` for independent | The git tag pattern to use. Supports interpolation of `{version}`, `{projectName}`, and `{releaseGroupName}` |
| **requireSemver**        | boolean | `false`                                                           | Whether to require that all tags match semantic versioning                                                   |
| **strictPreid**          | boolean | `false` for independent, `true` for fixed release groups          | Whether to ensure prerelease IDs are consistent across packages                                              |
| **preferDockerVersion**  | boolean | `false`                                                           | Whether to prefer Docker-compatible version format in git tags                                               |
| **checkAllBranchesWhen** | string  | undefined                                                         | Branch to check when resolving current versions from git tags                                                |

#### Tag Pattern Syntax

The tag pattern supports interpolating the following values:

- `{version}` - The version currently being released
- `{projectName}` - The name of the project being released (for independent releases)
- `{releaseGroupName}` - The name of the release group being released (when using release groups)

Example patterns and their results:

- `v{version}` → `v1.0.0` (default for fixed releases)
- `{projectName}@{version}` → `my-lib@1.0.0` (default for independent releases)
- `{releaseGroupName}/{projectName}/{version}` → `backend/api/1.0.0`
- `release/{version}` → `release/1.0.0`

#### Example Configuration

{% tabs syncKey="nx-release-configuration" %}
{% tabitem label="Nx 22+" %}

```jsonc
// nx.json
{
  "release": {
    "releaseTag": {
      "pattern": "{releaseGroupName}-v{version}",
      "requireSemver": true,
      "strictPreid": true,
      "preferDockerVersion": false,
      "checkAllBranchesWhen": "main"
    }
  }
}
```

{% /tabitem %}
{% tabitem label="Nx < 22" %}

```jsonc
// nx.json
{
  "release": {
    "releaseTagPattern": "{releaseGroupName}-v{version}",
    "releaseTagPatternRequireSemver": true,
    "releaseTagPatternStrictPreid": true,
    "releaseTagPatternPreferDockerVersion": false,
    "releaseTagPatternCheckAllBranchesWhen": "main"
  }
}
```

{% /tabitem %}
{% /tabs %}

### Version

The `version` property configures the versioning phase of the release process. It is used to determine the next version of your projects, and update any projects that depend on them to use the new version.

{% aside type="note" title="Breaking Changes in Nx v22" %}
In Nx v22, the legacy versioning implementation was removed entirely. This had been deprecated since Nx 21.
An automated migration was provided in Nx v21 to update your configuration to the new format when running `nx migrate`.

For Nx 22, this automated migration was re-added to allow updating your configuration by running `nx migrate`.
{% /aside %}

Behind the scenes, ecosystem-specific `version` logic is powered by a `VersionActions` implementation. Out of the box Nx wires up the most widely applicable `VersionActions` implementation for you, which is `@nx/js/src/release/version-actions` provided by the `@nx/js` plugin.

{% aside type="note" title="Programmatic API (Nx 22+)" %}
For advanced use cases, the `ReleaseClient` programmatic API allows you to trigger releases from custom scripts. In Nx 22+, you can optionally ignore the `nx.json` release configuration entirely when using the API, which is useful for ad-hoc scripts that only work with a subset of the repository.
{% /aside %}

Core version options are therefore directly at the top level of the `version` property (as of Nx v21), while ecosystem-specific options are available through `versionActionsOptions`:

```jsonc
// nx.json
{
  "release": {
    "version": {
      // Core options
      "conventionalCommits": true,
      "manifestRootsToUpdate": ["dist/packages/{projectName}"],
      // Ecosystem-specific options
      "versionActionsOptions": {
        "skipLockFileUpdate": true
      }
    }
  }
}
```

Some important changes in Nx 22:

- `preserveMatchingDependencyRanges` now defaults to `true` (previously `false`)
  - When `true`, dependency version ranges are preserved if they already satisfy the new version being released
  - Example: If releasing version `1.2.0` and a dependent has range `^1.0.0`, it remains `^1.0.0` instead of being updated to `1.2.0`
  - Set to `false` explicitly if you need exact versions in all dependents
- `updateDependents` now defaults to `"always"` (previously `"auto"`)
  - `"always"`: Update dependents wherever they exist in the graph, regardless of filter selection
  - `"auto"`: Update dependents only if they're within the selected projects or release groups
  - `"never"`: Never update dependents
- `releaseTag*` properties such as `releaseTagPattern` and `releaseTagPatternStrictPreid` have been coalesced into a single `releaseTag` object. (`releaseTagPattern` -> `releaseTag.pattern`, `releaseTagPatternStrictPreid` -> `releaseTag.strictPreid`)
- `releaseTag.strictPreid` now defaults to `true`
- Fixed Release Group Release Tag Pattern now defaults to `{releaseGroupName}-v{version}`

### Changelog

The `changelog` property configures the changelog phase of the release process. It is used to generate a changelog for your projects, and commit it to your repository.

There are two types of possible changelog that can be generated:

- **Workspace Changelog**: A changelog that contains all changes across all projects in your workspace. This is not applicable when releasing projects independently.

- **Project Changelogs**: A changelog that contains all changes for a given project.

The `changelog` property is used to configure both of these changelogs.

#### Workspace Changelog

The `changelog.workspaceChangelog` property configures the workspace changelog. It is used to determine if and how the workspace changelog is generated.

```jsonc
// nx.json
{
  "release": {
    "changelog": {
      // This disables the workspace changelog
      "workspaceChangelog": false
    }
  }
}
```

```jsonc
// nx.json
{
  "release": {
    "changelog": {
      "workspaceChangelog": {
        // This will create a GitHub release containing the workspace
        // changelog contents
        "createRelease": "github",
        // This will disable creating a workspace CHANGELOG.md file
        "file": false
      }
    }
  }
}
```

#### Project Changelogs

The `changelog.projectChangelogs` property configures the project changelogs. It is used to determine if and how the project changelogs are generated.

```jsonc
// nx.json
{
  "release": {
    "changelog": {
      // This enables project changelogs with the default options
      "projectChangelogs": true
    }
  }
}
```

```jsonc
// nx.json
{
  "release": {
    "changelog": {
      "projectChangelogs": {
        // This will create one GitHub release per project containing
        // the project changelog contents
        "createRelease": "github",
        // This will disable creating any project level CHANGELOG.md
        // files
        "file": false
      }
    }
  }
}
```

#### Replace Existing Contents {% badge  text="Nx 22+" /%}

By default, changelog entries are prepended to existing changelog files. To completely replace the entire changelog file contents instead, use the `replaceExistingContents` option:

```jsonc
// nx.json
{
  "release": {
    "changelog": {
      "workspaceChangelog": {
        // Replaces the entire CHANGELOG.md file with the new content
        "replaceExistingContents": true
      }
    }
  }
}
```

This option is available for both `workspaceChangelog` and `projectChangelogs`. It's useful when you want to regenerate the entire changelog from scratch rather than maintaining a cumulative history.

### Git

The `git` property configures the automated git operations that take place as part of the release process.

```jsonc
// nx.json
{
  "release": {
    "git": {
      // This will enable committing any changes (e.g. package.json
      // updates, CHANGELOG.md files) to git
      "commit": true,
      // This will enable create a git for the overall release, or
      // one tag per project for independent project releases
      "tag": false
    }
  }
}
```

### Docker {% badge  text="experimental" /%}

{% aside type="caution" title="Experimental Feature" %}
Docker support in Nx is currently experimental and may undergo breaking changes without following semantic versioning.
{% /aside %}

The `docker` property configures Docker image versioning and publishing when using `nx release`. This enables calendar-based versioning schemes and automated Docker registry publishing as part of your release workflow.

```jsonc
// nx.json
{
  "release": {
    // Simple configuration - enables Docker with defaults
    "docker": true
  }
}
```

```jsonc
// nx.json
{
  "release": {
    "docker": {
      // Run this command before versioning Docker images
      "preVersionCommand": "npx nx run-many -t docker:build",

      // Define versioning schemes for different environments
      "versionSchemes": {
        "production": "{currentDate|YYMM.DD}.{shortCommitSha}",
        "hotfix": "{currentDate|YYMM.DD}.{shortCommitSha}-hotfix",
        "staging": "{currentDate|YYMM.DD}-staging",
        "development": "{currentDate|YYMM.DD}-dev-{shortCommitSha}"
      },

      // Skip Docker versioning for these projects to prevent versioning with other tools like NPM
      // Only set this if you are not using {versionActionsVersion} in your docker version scheme
      "skipVersionActions": ["api"],

      // Default Docker repository name (can be overridden per project)
      "repositoryName": "myorg",

      // Docker registry URL
      "registryUrl": "docker.io"
    }
  }
}
```

Read more about it in the [Release Docker Images guide](/docs/guides/nx-release/release-docker-images).

#### Docker Plugin Options

When configuring the `@nx/docker` plugin in `nx.json`, you can customize the behavior of Docker build and run targets. One important option is `skipDefaultTag`:

```jsonc
// nx.json
{
  "plugins": [
    {
      "plugin": "@nx/docker/plugin",
      "options": {
        "buildTarget": {
          "name": "docker:build",
          // Skip the default --tag argument
          "skipDefaultTag": true,
          // You must provide your own tags via args
          "args": ["--tag myorg/myapp:latest", "--tag myorg/myapp:1.0.0"]
        }
      }
    }
  ]
}
```

**Important:** Setting `skipDefaultTag: true` opts out of Nx Release support for that project. When you explicitly manage your own Docker tags via the `args` property, the automatic versioning and publishing features of `nx release` will not work for those Docker projects. Only use `skipDefaultTag: true` if you are not using `nx release` to manage your Docker image versions.

If you want to use `nx release` with Docker projects, leave `skipDefaultTag` as `false` (the default) or omit it entirely.

#### Version Scheme Syntax

Docker version schemes support calendar-based patterns using the following placeholders:

- `{projectName}` - The name of the project being released
- `{currentDate}` - Current date in ISO format (e.g., 2025-01-30T14:30:00Z)
- `{currentDate|FORMAT}` - Current date with custom format using these tokens:
  - `YYYY` - 4-digit year (e.g., 2025)
  - `YY` - 2-digit year (e.g., 25)
  - `MM` - 2-digit month (01-12)
  - `DD` - 2-digit day (01-31)
  - `HH` - 2-digit hour in 24-hour format (00-23)
  - `mm` - 2-digit minutes (00-59)
  - `ss` - 2-digit seconds (00-59)
- `{shortCommitSha}` - First 7 characters of the current commit SHA
- `{commitSha}` - Full commit SHA
- `{versionActionsVersion}` - The version generated during the version actions such as "1.2.3"

Example patterns:

- `{currentDate|YYMM.DD}.{shortCommitSha}` - Results in: 2501.30.a1b2c3d
- `{projectName}-{currentDate|YYYY.MM.DD}` - Results in: api-2025.01.30
- `{currentDate|YY.MM.DD.HHmm}-{commitSha}` - Results in: 25.01.30.1430-abcdef1234567890
- `{projectName}-{versionActionsVersion}` - Results in: api-1.2.3

#### Group-Level Docker Configuration

You can configure [Docker release](/docs/guides/nx-release/release-docker-images) settings at the release group level:

```jsonc
// nx.json
{
  "release": {
    "groups": {
      "backend": {
        "projects": ["api"],
        "projectsRelationship": "independent",
        "docker": {
          // Only set this to true if you are not using {versionActionsVersion} in your docker version scheme
          "skipVersionActions": true
          // Run a script before tagging Docker version
          "groupPreVersionCommand": "echo Preparing backend release",
        },
        "changelog": {
          "projectChangelogs": true
        }
      }
    }
  }
}
```

This allows you to have other releases such as [NPM](/docs/guides/nx-release/release-npm-packages) or [Rust crates](/docs/guides/nx-release/publish-rust-crates) in the same workspace.

## Sync

These are global configuration options for the [`nx sync`](/docs/reference/nx-commands#nx-sync) command. The `nx sync` command runs all global and task-specific [sync generators](/docs/concepts/sync-generators) to ensure that your files are in the correct state to run tasks or start the CI process.

```jsonc
// nx.json
{
  "sync": {
    "applyChanges": true,
    "globalGenerators": ["my-plugin:my-sync-generator"],
    "generatorOptions": {
      "my-plugin:my-sync-generator": {
        "verbose": true
      }
    },
    "disabledTaskSyncGenerators": ["other-plugin:problematic-generator"]
  }
}
```

| Property                       | Description                                                                                                                                                                                                                                                                                  |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **applyChanges**               | Whether to automatically apply task sync generator changes when running tasks. If not set, the user will be prompted. If set to `true`, the user will not be prompted and the changes will be applied. If set to `false`, the user will not be prompted and the changes will not be applied. |
| **globalGenerators**           | Sync generators that are only run when the `nx sync` command is executed. These are not associated with a particular task.                                                                                                                                                                   |
| **generatorOptions**           | Options to be passed to sync generators                                                                                                                                                                                                                                                      |
| **disabledTaskSyncGenerators** | Globally disable specific task sync generators                                                                                                                                                                                                                                               |

## Generators

Default generator options can be configured in `nx.json`. For instance, the following tells Nx to always
pass `--buildable=true` when creating new libraries with the `@nx/js` plugin.

```json
// nx.json
{
  "generators": {
    "@nx/js:library": {
      "buildable": true
    }
  }
}
```

## Extends

Some presets use the `extends` property to hide some default options in a separate json file. The json file specified in the `extends` property is located in your `node_modules` folder. The Nx preset files are specified in [the `nx` package](https://github.com/nrwl/nx/tree/master/packages/nx/presets).

## Nx Cloud

There are also options for [Nx Cloud](https://nx.app) that are set in the `nx.json` file. For instance, you connect to the Nx Cloud service using an `nxCloudId` like this:

```json
// nx.json
{
  "nxCloudId": "SOMEID"
}
```

If connecting to a different Nx Cloud instance, you can define the `nxCloudUrl`:

> The default is `https://cloud.nx.app`

```json
// nx.json
"nxCloudUrl": "https://nx.custom-company-domain.net"
```

For more details on configuring Nx Cloud, see the [Nx Cloud Configuration Options page](/docs/reference/nx-cloud-cli).

## Max Cache Size

The `maxCacheSize` property in `nx.json` allows you to set a limit on the size of the local cache. If it is not set, Nx defaults to a maximum size of 10% of the size of the disk where the cache is stored, up to a maximum of 10GB. This means that if your disk is 100GB, the maximum cache size will be 10GB. If the cache exceeds the specified size, Nx removes the least recently used cache entries until the total size is below 90% of the specified limit.

You can also override this value using the `NX_MAX_CACHE_SIZE` environment variable, which accepts the same units and takes precedence over the `maxCacheSize` option in `nx.json`.

This behavior can be opted out by setting `maxCacheSize` to `0`.

Valid values for `maxCacheSize` can be specified in bytes, kilobytes (KB), megabytes (MB), or gigabytes (GB). For example, any of the following would be valid values:

| Value    | Description                                                      |
| -------- | ---------------------------------------------------------------- |
| `819200` | 819200 bytes (800 KB)                                            |
| `100MB`  | 100 megabytes (100 \* 1024 \* 1024 bytes)                        |
| `1GB`    | 1 gigabyte (1024 \* 1024 \* 1024 bytes)                          |
| `0`      | No limit on the local cache size (disables the cache size limit) |

```json
// nx.json
{
  "maxCacheSize": "0" // No limit on the local cache size
}
```

```json
// nx.json
{
  "maxCacheSize": "10GB" // Set the maximum cache size to 10 gigabytes
}
```

Regardless of the `maxCacheSize` setting, Nx will remove cache entries that have not been accessed in the last 7 days.

## TUI

The `tui` property in `nx.json` configures the [Terminal UI](/docs/guides/tasks--caching/terminal-ui). It allows you to enable or disable the TUI and configure its behavior.

```json
// nx.json
{
  "tui": {
    // Enable the Nx TUI
    "enabled": true,
    // Automatically exit the TUI when completed
    // Use a number to specify the seconds to keep the TUI open for after completion
    "autoExit": true
  }
}
```

## Conformance

The `conformance` property in `nx.json` configures the usage of [Nx Conformance](/docs/enterprise/conformance).

```jsonc
// nx.json
{
  "conformance": {
    "outputPath": "dist/conformance-result.json",
    "rules": [
      {
        "rule": "@nx/conformance/enforce-module-boundaries",
        "status": "evaluated",
        "explanation": "This rule ensures proper module boundaries are maintained across the workspace"
      },
      {
        "rule": "./tools/local-conformance-rules/check-project.ts",
        "projects": ["*"],
        "options": {
          "strictMode": true
        }
      },
      {
        "rule": "nx-cloud://my-custom-rule",
        "projects": [
          "frontend-*",
          {
            "matcher": "backend-legacy",
            "explanation": "Legacy backend project is exempt until migration is complete"
          }
        ],
        "status": "enforced"
      }
    ]
  }
}
```

### Configuration Options

| Property       | Type                | Description                                                                                                                                           |
| -------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **outputPath** | `string \| false`   | Optional path to write the conformance results to. Defaults to `"dist/conformance-result.json"`. Set to `false` to disable writing results to a file. |
| **rules**      | `Array<RuleConfig>` | List of conformance rules to apply to your workspace.                                                                                                 |

### Rule Configuration

Each rule in the `rules` array can have the following properties:

| Property        | Type                                                        | Required | Description                                                                                                                                                                                              |
| --------------- | ----------------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **rule**        | `string`                                                    | Yes      | Relative path to a local rule implementation, node_module path, or nx-cloud rule ID for Nx Cloud Enterprise (e.g., `"nx-cloud://my-rule"`).                                                              |
| **options**     | `Record<string, unknown>`                                   | No       | Rule-specific configuration options. The available options depend on the specific rule being used.                                                                                                       |
| **projects**    | `Array<string \| { matcher: string; explanation: string }>` | No       | Projects to apply the rule to. See [Projects](#projects-conformance) section below.                                                                                                                      |
| **explanation** | `string`                                                    | No       | Optional explanation to communicate to colleagues why this rule is enabled and important to the workspace.                                                                                               |
| **status**      | `"enforced" \| "evaluated" \| "disabled"`                   | No       | Override the default status of the rule (defaults to `"enforced"`). If set to `"evaluated"`, violations are reported but don't cause failures. If set to `"disabled"`, the rule is not evaluated at all. |

### Projects (Conformance)

If you want to limit the projects that a conformance rule applies to, you can use the `projects` property. This property accepts an array of strings which can be project names, glob patterns, directories, tag references or anything else that is supported by the `--projects` filter you may know from other commands such as `nx run`.

By default, the implied value is `["*"]` (all projects).

You can also use objects with `matcher` and `explanation` properties to document why specific projects are included or excluded from the rule.

```jsonc
{
  "rule": "my-rule",
  // Here we are configuring the rule to apply to all frontend projects
  // except the one called "frontend-legacy"
  "projects": ["frontend-*", "!frontend-legacy"]
}
```

```jsonc
{
  "rule": "my-rule",
  "projects": [
    "frontend-*",
    {
      "matcher": "!frontend-legacy",
      "explanation": "Exempt until migration to new architecture is complete"
    }
  ]
}
```

### Rule Status Values

- **enforced** (default): Rule violations will cause the conformance check to fail (exit code 1)
- **evaluated**: Rule violations are reported but don't cause failures (exit code 0)
- **disabled**: Rule is not evaluated at all
